4 research outputs found

    Monitoring distributed systems

    Get PDF
    In debugging distributed programs a distinction is made between an observed error and the program fault, or bug, that caused the error. Testing reveals an error; debugging is the process of tracing the error through time and space to the bug that caused it. A program is considered to be in error when some state of computation violates a safety requirement of the program. Expressing safety requirements in such a way that a computation can be monitored for safe behavior is thus a basic preliminary step in the testing-debugging cycle. Safety requirements are usually expressed as predicates. When a state of the computation violates such a safety predicate, that state can be said to be in error. A predicate logic is proposed that permits the specification of relationships between distributed predicates. This increases the scope and precision of situation-specific conditions that can be specified and detected. It also permits the specification of safety primitives such as P unless Q using distributed predicates. Thus a distributed program can be directly monitored for satisfaction and violation of safety requirements. Breakpoint conditions and predicates expressing safety may hold over a number of states of a program. A breakpoint state is meaningful if the causal relationships of events included in the breakpoint are unambiguous. At least two such states exist for each condition: the minimal and the maximal prefix of the computation at which the predicate holds. These states are specifiable as part of a breakpoint definition in the logic presented

    ENHANCED TELEPHONY USING HUMAN INAUDIBLE DATA OVER VOICE CHANNEL

    Get PDF
    A telephone, such as a mobile phone, places a telephone call to another telephone by transmitting a signal (e.g., digital or analog) indicative of a sound wave. The signal indicative of the sound wave encodes sound data over a voice channel. The sound data includes human audible data, such as data indicative of sounds (e.g., voice) captured by a microphone. That is, the frequency of the sound wave that encodes the human audible data is within a frequency range audible by humans. The sound data also includes human inaudible data, such as a telephone number of the calling device, an image of the caller, a location of the calling device, associated with the calling telephone or a user of the calling telephone. That is, the frequency of the sound wave that encodes the human inaudible data is above the frequency range audible by humans. When the recipient telephone receives the signal indicative of the sound data, the recipient telephone converts the signal to a human audible sound wave that encodes the human audible data. The recipient telephone may utilize the human inaudible data to enhance the functionality of the call. For example, the recipient telephone may display the human inaudible data (e.g., a phone number of the calling device and/or an image of the caller) or connect a video call via URL encoded in the human inaudible data

    Application of domain analysis to object-oriented systems

    No full text

    Patterns (Panel)

    No full text
    corecore